As programming approaches and foundations have evolved, application programming interfaces (APIs) and programming schemas have been developed to standardize and unify programming methodologies that were previously multi-variant and relatively incompatible. Modem programming therefore often involves employing APIs and schemas in conjunction with reusable libraries. Unfortunately, this evolution has inadvertently created many inefficient programming artifacts that are actually spread and perpetuated by these standardizations programming constructs. For example, one resulting software programming artifact is a duality between reference types and value types.
Reference types are variables that are stored on a heap and referenced by a pointer stored on the stack. Value types are variables that are stored directly on the stack. Consequently, variables that are represented as reference types can be uninitialized (termed “null”), but variables that are represented as value types cannot be established in an uninitialized condition without risking indeterminate or even catastrophic results. This nullification issue can present problems in a myriad of situations, including data base accessing.
Support for nullability across all types, including value types, is essential when interacting with null supported languages, such as database languages (e.g., SQL). A database language may use a null value to indicate that the actual data value is unknown or missing. By providing null support within a general purpose programming language null-supported languages and programming languages may be integrated (e.g., code in the C# programming language may read, write or interpret nullable fields in a database language).
General purpose programming languages have historically provided little or no null support. Many approaches exist for handling nulls and value types without direct language support, but all have shortcomings. For example, one approach is to use a “special” value (such as −1 for integers) to indicate null, but this only works when an unused value can be identified. Another approach is to maintain Boolean null indicators in separate fields or variables, but this does not work well for parameters and return values. A third approach is to use a set of user-defined nullable types, but this only works for a closed set of types.
Certain general purpose programming languages supply a nullable type (e.g., C# 2.0) to provide for nullability across all types, including value types. A nullable type may be implemented using a multi-element structure containing a Boolean null indicator and an element which contains the value of the instance of the nullable type when the instance of the nullable type does not represent null. Although the nullable type provides a method for setting a value type to null, the structure used to implement the nullable type is itself an instance of a value type. Use of a structure that is inherently an instance of a value type to represent an instance of a reference type leads to inconsistent and counterintuitive results under certain circumstances.